IRIX Base Documentation 2001 May

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Base Documentation 2001 May / SGI IRIX Base Documentation 2001 May.iso / usr / share / catman / u_man / cat1 / mkf2c.z / mkf2c

Wrap

Text File | 1998-10-30 | 17.2 KB | 416 lines

MMMMKKKKFFFF2222CCCC((((1111)))) MMMMKKKKFFFF2222CCCC((((1111)))) NNNNAAAAMMMMEEEE mkf2c - generate FORTRAN-C interface routines SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS mmmmkkkkffff2222cccc [ options ] [ cprog.fc [ cprog.s ] ] DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN _m_k_f_2_c is used to generate assembly-language routines to provide greater flexibility when calling a C function from a FORTRAN routine. _M_k_f_2_c accepts as input a set of C functions, and produces an assembly- language interface routine in the output file. If the input and output files are not specified, _m_k_f_2_c reads from _s_t_d_i_n and writes to _s_t_d_o_u_t. The input may be a copy of the actual C file being interfaced, perhaps filtered by the program _e_x_t_c_e_n_t_r_y(1). The output of _m_k_f_2_c is an assembly-language (._s) file that must be assembled with _a_s(1), and loaded with the FORTRAN and C routines that are to be interfaced. The assembly-language output is KPIC code which must be assembled with the ----KKKKPPPPIIIICCCC option to _a_s(1) unless an _u_n_s_h_a_r_e_d .o is desired. _M_k_f_2_c uses the parameter declarations in the C function headers to transform each parameter of the calling language to that of the receiving language. The standard basic C types attached to the parameters are used to determine the object each parameter represents - i.e., whether it is a value or pointer, its size, whether it is unsigned, etc. For C functions in K&R style, the opening and closing brace of the function body must be present. Information in the body of the function is ignored. For C functions in ANSI C function prototype style, the function may be either a definition (and whatever is between the opening and closing brace is ignored) or a declaration (ie, with ; rather than {}). Function parameters in ANSI C style function prototypes need not name the parameters. Function parameters in ANSI C style function prototypes cannot use typedef names to declare parameter types. _m_k_f_2_c expects its input to consist solely of the functions it is to interface, comments, and lines which begin with the preprocessor control character '#'. It can match braces, enabling it to bound function bodies. It cannot, however, understand other C constructs normally occurring at the global level (typedefs, structure declarations, data declarations, function prototypes, etc.). Such unrecognized constructs must be eliminated from the input (this is the purpose of _e_x_t_c_e_n_t_r_y(1)). _M_k_f_2_c will ignore functions of storage class _s_t_a_t_i_c . The simplest way to generate an interface for a C function is to simply hand-code a copy of the function which consists of the entry and parameter declarations with an empty body. This stub, which is traditionally suffixed with ._f_c is then used as input to _m_k_f_2_c, and the resultant ._s file is assembled and linked into the executable. The root name of the stub file must differ from the root name of the file PPPPaaaaggggeeee 1111 MMMMKKKKFFFF2222CCCC((((1111)))) MMMMKKKKFFFF2222CCCC((((1111)))) containing the actual C functions (so that the name of the resultant ._os differ). NOTE: _t_h_e -KPIC _s_w_i_t_c_h _m_u_s_t _b_e _g_i_v_e_n _t_o as(_1) _u_n_l_e_s_s _t_h_e _o_b_j_e_c_t _i_s _t_o _b_e non-shared. mkf2c foo.fc foo.s as -KPIC foo.s -o foo.o It is also possible to create wrappers from existing C source code. This is done by adding special rules to your makefile and adding special comments around each function for which an interface is to be generated. See the example at the end of this man page. The options to _m_k_f_2_c(1) are the following: ----33332222 Generate wrappers with (old) 32-bit calling conventions. At this time, it is the default, but may change as different ABIs become the future default. ----66664444 Generate wrappers with 64-bit pointer sizes, and using the 64 bit calling conventions. ----nnnn33332222 Generate wrappers with the n32 calling conventions. ----ffff Suppress extending floats to doubles across the call. Normally, formal parameters of type _f_l_o_a_t in the (K&R) C input to _m_k_f_2_c are dereferenced and converted to type _d_o_u_b_l_e across the interface, to conform to C calling conventions. This option suppresses the conversion to _d_o_u_b_l_e. If this option is selected, the receiving routine in C should have a _p_r_o_t_o_t_y_p_e with the _f_l_o_a_t parameters declared correctly. For declarations input to _m_k_f_2_c in ANSI C style function prototypes float arguments are not extended, so ----ffff need not be supplied. ----oooo _o_u_t_p_u_t Name the output file _o_u_t_p_u_t. If the output filename is not specified by a -_o _f_i_l_e_n_a_m_e switch, _m_k_f_2_c will use the second filename appearing in its argument list as the output file name. This method must be used if it is desired to generate an interface routine in a file when the input is from _s_t_d_i_n. ----UUUU Normally, upper case characters appearing in FORTRAN external names are mapped to lower case. This option suppresses that mapping, allowing FORTRAN external names to be of mixed case. This option should be used in conjunction with the -_U option to _f_7_7(_1). ----ssssiiiiggggnnnneeeedddd,,,,----uuuunnnnssssiiiiggggnnnneeeedddd Specify the _s_i_g_n_e_d attribute of single-character parameters. The setting of this option determines whether a scalar parameter of type _c_h_a_r (in the C input to _m_k_f_2_c), which corresponds to a FORTRAN argument of type _c_h_a_r_a_c_t_e_r*_1, should be sign-extended across the interface. The default setting is _u_n_s_i_g_n_e_d. PPPPaaaaggggeeee 2222 MMMMKKKKFFFF2222CCCC((((1111)))) MMMMKKKKFFFF2222CCCC((((1111)))) ----uuuu Keep underscores in function names. By default underscores are removed and a warning is issued. ----llll By default, _m_k_f_2_c truncates FORTRAN external names to _s_i_x characters to conform to the ANSI standard and to be backwards-compatible with the IRIS 4D Series. This switch allows the maximum number of characters in FORTRAN external names to be the same as that enforced by the FORTRAN front-end (currently 32). If this switch is _n_o_t specified, the FORTRAN program should have the C function name truncated to _s_i_x characters at the call. ----wwww Inhibit the generation of warning messages. As creating _w_r_a_p_p_e_r_s can cause confusion, _m_k_f_2_c gives warning messages for constructs which will result in an interface which is 'unnatural' for C (i.e., in which the C side of the interface must take special precautions when accessing the parameters or naming the routines). An example of this would be passing a FORTRAN character variable as a C character array. _M_k_f_2_c knows that this situation requires C to use special care when manipulating the string, as it is not null-terminated, and, hence, it generates a warning message. It is recommended that -_w only be used by programmers experienced with the generation of _w_r_a_p_p_e_r_s. ----ccccaaaallllllll____ssssaaaammmmeeee____ddddssssoooo This is used when the wrapper and the target C function will be placed in the same DSO. A further optimization is taken which removes the restoring of the gp register after the call return. EEEEXXXXAAAAMMMMPPPPLLLLEEEE In this example, a FORTRAN program wants to call a C function _A_l_l_P_a_r_a_m_e_t_e_r_s with many parameters. The FORTRAN program is in the file _f._f and the C function is in the file _c._c. These are the only two files in the program. The special comments /*CENTRY*/ and /*ENDCENTRY*/ have been added to the C source code to bracket the function for which an interface is to be generated. The C function header is given below: PPPPaaaaggggeeee 3333 MMMMKKKKFFFF2222CCCC((((1111)))) MMMMKKKKFFFF2222CCCC((((1111)))) /* CENTRY */ AllParameters(i,s,c,cptr,ptr1,ptr2,ar1,f,d,d1,struct1,string1,string2,u) short s; char c,*cptr; int *ptr1; char *ptr2[]; short ar1[]; float f; double d,*d1; struct test_s *struct1; char string1[],string2[30]; sometype u; { /* The C function body is ignored by _m_k_f_2_c. */ } /* ENDCENTRY */ When this function is run through _m_k_f_2_c, a complaint will be given about not understanding the type of parameter _u. It will be assumed to be a simple pointer. Additionally, a warning about passing the parameters _s_t_r_i_n_g_1 and _s_t_r_i_n_g_2 as simple pointers will be given. (These FORTRAN character variables each have an associated length which is passed as a _h_i_d_d_e_n parameter to the C function, at the end of the parameter list. These additional parameters may be accessed by the C function by the use of the _v_a_r_a_r_g_s macros. See the _F_O_R_T_R_A_N _L_a_n_g_u_a_g_e _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l for more information.) The parameter _i will be assumed to be of type _i_n_t, as it is by the C compiler _c_c_o_m during compilation. Several items are noteworthy about the parameters in this example. The parameters _i, _s, _c, _f, and _d will be dereferenced across the call. The parameter _f will be extended to a _d_o_u_b_l_e across the call unless the -_f switch is given to _m_k_f_2_c(1). The parameters _p_t_r_1, _p_t_r_2, _a_r_1, _d_1, _s_t_r_u_c_t_1, _s_t_r_i_n_g_1, and _s_t_r_i_n_g_2 will be passed as simple pointers. The FORTRAN character*1 variable which is passed as _c will be dereferenced and extended to a long across the call. If the -_s_i_g_n_e_d switch is specified, _c will be sign-extended when being dereferenced. A copy of parameter _c_p_t_r will be made and the copy null-terminated. A pointer to this copy will PPPPaaaaggggeeee 4444 MMMMKKKKFFFF2222CCCC((((1111)))) MMMMKKKKFFFF2222CCCC((((1111)))) be passed. The C entry point will be named _A_l_l_P_a_r_a_m_e_t_e_r_s. The FORTRAN entry point name depends on whether or not the -_U and/or the -_l switches have been given. The various combinations of these switches and their effect is detailed below: ___________________________ Switches FORTRAN Entry ___________________________ <_n_o_n_e> allpar_ -_l allparameters_ -_U AllPar_ -_l -_U AllParameters_ ___________________________ ||||||| ||||||| ||||||| The program can be made easily and the interface generated automatically by adding the following special rules to your makefile: # .fc must be added to your SUFFIXES between .c and .o .SUFFIXES: .SUFFIXES: .o .fc .c .s .f F2CFLAGS= ASFLAGS=-KPIC test: f.o c.o f77 -o test f.o c.o # note -- each .c file containing routines to be interfaced must have # a dependency such as the following c.o: c.fc .fc.o: cc $(CFLAGS) -c $*.c mkf2c $(F2CFLAGS) $< $*.s as $(ASFLAGS) -o $*.wo $*.s ld -r $*.o $*.wo -o $*.tmp mv $*.tmp $*.o rm -f $*.s $*.wo .c.fc: extcentry $*.c $*.fc clean: rm -f *.o test *.fc In the make, the program _e_x_t_c_e_n_t_r_y will be run on _c._c to produce _c._f_c. This program (see _e_x_t_c_e_n_t_r_y(1)) will copy to _c._f_c all text in _c._c which is between the special comments /* _C_E_N_T_R_Y */ and /* _E_N_D_C_E_N_T_R_Y */. _M_k_f_2_c PPPPaaaaggggeeee 5555 MMMMKKKKFFFF2222CCCC((((1111)))) MMMMKKKKFFFF2222CCCC((((1111)))) will then be run on _c._f_c, and the make variable _F_2_C_F_L_A_G_S will be passed to it. The C source will be compiled with _c_c(1) (using _c_c $_C_F_L_A_G_S), and the output of _m_k_f_2_c will be assembled (with _a_s $_A_S_F_L_A_G_S). These two ._os will then be loaded together into a single relocatable named _c._o. If it is desired to pass _m_k_f_2_c(1) some flags (e.g., -_l and -_s_i_g_n_e_d), the _m_a_k_e variable _F_2_C_F_L_A_G_S should be set in the makefile, as F2CFLAGS = -signed -l SSSSEEEEEEEE AAAALLLLSSSSOOOO extcentry(1), cc(1), FORTRAN Language Reference Manual DDDDIIIIAAAAGGGGNNNNOOOOSSSSTTTTIIIICCCCSSSS _M_k_f_2_c is very simple-minded about diagnosing syntax errors. It can detect such things as a formal parameter having its type declared when it is not in the formal parameter list. A few such cases give intelligible error messages. The program will complain about types it does not understand. The default type assigned in such cases is _s_i_m_p_l_e _p_o_i_n_t_e_r. _M_k_f_2_c will also delete characters from FORTRAN entry names which are illegal (e.g., underscores). The user will be warned in such instances. Most errors that the programs detect are indicated only by the source line number. If _m_k_f_2_c encounters an error which it cannot remedy, it will abort, giving the line number on which the error occurred. The resultant ._s file will be removed, and an error exit will be taken. Because of its limited error diagnostic ability, it is advisable to use _c_c (_1) to determine whether the input syntax is correct before passing it to _m_k_f_2_c. BBBBUUUUGGGGSSSS _m_k_f_2_c does not understand the ANSI notation a(void) _a_s _m_e_a_n_i_n_g _a _f_u_n_c_t_i_o_n _w_i_t_h _n_o _a_r_g_u_m_e_n_t_s. In ANSI C style function prototypes, typedef names cannot be used. AAAAUUUUTTTTHHHHOOOORRRR Greg Boyd PPPPaaaaggggeeee 6666